.\" Manpage for npd6.conf
.\" Contact sgroarke@gmail.com to correct errors or typos.
.TH man 5 "07 August 2011" "0.4.1" "npd6.conf man page"
.SH NAME
npd6.conf \- configuration file for neighbor proxy daemon ipv6 npd6

.SH DESCRIPTION
This file contains parameters which affect the manner of npd6's operation. One part contains parameters which will required to be set as required per-site. The second set are less likely to require changing and will typically work fine at their default value. Conversely, if set wrongly, these parameters can stop npd6 working at all.


.SS General parameters
.BR "prefix = " "[prefix]"
.RS
This defines the prefix which will be matched against received Neighbor Solicitations. It will often be a /64 supplied by an ISP, but this is by no means mandatory.

The prefix requires a terminating colon, e.g.
.RS
.B prefix=2a01:123:456:7:
.RE

Note that leading zeros are not required, but can be used. So
prefix=2a01:0123:0456:0007:
is equivalent to
prefix=2a01:123:456:7:
.RE

.BR "interface = " "[interfacename]"
.RS
This defines the interface to which we will bind and listen. Note also that this is the interface whixh will, by default (see below), have the multicast flag enabled if required too.

It will typically be one of the ethernet interfaces, e.g.
.RS
.B interface=eth0
.RE
.RE

.BR "listtype = " "[none|black|white]"
.RS
This defines the type of "listing" (if any) to be performed: whitelisting, blacklisting or none at all.

If
.B black
or
.B white
is specified then you should also then define at least 1 (and as many more as you require) config items of the form

.RS
.B addrlist =
<ipv6 address>

e.g.
.B addrlist = 2a01:0123:456:7::22
(All the usual formats are supported.)
.RE

to supply the list of addresses to be either white- or black-listed.

Note that this config item must be before the
.B addrlist
items in the config file.

.B Behaviour with no black- or whitelisting

This is the default mode of oepration and likelt what most people will want. In this mode (the original mode before this feature was introduced) any Neighbor Solicitation received with a target address which matches the prefix will be answered by an appropriate Neighbor Advertisement, irrespective of whether or not that target actually exists and/or is reachable from here.

.B Behaviour with blacklisting

This mode of operation modifies how npd6 behaves: when a Neighbor Solicitation is received with a prefix which matches that configured, before a Neighbor Advertisement is generated in reply the target is additionally checked against the list of addresses defined. If it matches one of those addresses then the Neighbor Solicitation is silently ignored and no response generated.

.B Behaviour with whitelisting

This mode of operation modifies how npd6 behaves: when a Neighbor Solicitation is received with a prefix which matches that configured, before a Neighbor Advertisement is generated in reply the target is additionally checked against the list of addresses defined. Only if it matches one of those addresses is a Neighbor Solicitation is generated in response.
.RE


.SS Special parameters
.BR "collectTargets = " "amount"
.RS
Optionally, npd6 can record a list of targets received in the incoming Neighbor Solicitations, to which it has replied. These can be displayed in the defined log by sending a USR2 signal to the npd6 PID.

This paramater defines a limit to the number of addresses recorded. If the value is zero, then the feature is disabled. This is the default behaviour. The paramater should be set to a suitably large but sane value. The only significant overhead is memory (for storing the addresses) Given the address space of IPv6 and the possibility of receving very many different target addresses to not provide a celing to this recording would potentially open npd6 up to a denial-of-service based upon memory depletion.

In a typical situation, where a network might expect to receive Neighbor Solicitations for several dozen devices, there's likely no harm in setting this to 100 or 1000. Just don't set it at 10,000,000 without thinking first. Memory is only allocated as-required, so the initial overhead would not be an issue.

.RE

.B "linkOption = " "false|true"
.RS
Normal RFC-compliant behaviour requires that if npd6 is replying to a multicast Neighbor Solicitation it must include the Target Link-Layer option in any reply. However if replying to a unicast Neighbor Solicitation this option is not required. Hence it is normally not used unless enabled here by changing the this to
.B true

Default: false
.RE

.B "ignoreLocal = " "false|true"
.RS
If npd6 receives a Neighbor Solicitation for the global address of the interface to which it is bound, if set to
.B true
npd6 will ignore and not reply - this is since ordinarily the kernel will itself automatically respond to such a situation.

If changed from the default and set to
.B false
then such Neighbor Solcitations will be responded to - possibly resulting in duplicated Neighbor Advertisements.

Default: true
.RE

.B "routerNA = " "false|true"
.RS
Normal RFC-compliant behaviour requires that outgoing Neighbor Advertisements have the ROUTER flag set in them. This will be done unless disabled by changing the this to
.B false.

Default: true
.RE




.B "maxHops = " "[0-255]"
.RS
Outgoing Neighbor Advertisements will normally have their maximum hop value set to 255. if set incorrectly no anomaly in the operation of npd6 will be seen - however Neghbor Advertisements generated by npd6 may be silently ignored by the receiving device. Do not change without good reason.

Default: 255
.RE




.SH SEE ALSO
npd6(8)

.SH BUGS
No known bugs - Please report them to npd6Project@gmail.com
.SH AUTHOR
Sean Groarke (sgroarke@gmail.com)
